<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
            "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>



<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<META name="GENERATOR" content="hevea 1.08">
<LINK rel="stylesheet" type="text/css" href="obsman.css">
<TITLE>
Porting to Standalone Eplex
</TITLE>
</HEAD>
<BODY >
<A HREF="obsman003.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="obsman005.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
<HR>

<H1 CLASS="chapter"><A NAME="htoc46">Chapter&nbsp;4</A>&nbsp;&nbsp;Porting to Standalone Eplex</H1>
<A NAME="eplexstandalone"></A>

Since ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> version 5.7, standalone eplex have become the standard
eplex, loaded with <CODE>lib(eplex)</CODE>. The previous <CODE>lib(eplex)</CODE>, which
loads eplex with the range bounds keeper and the IC variant have now been
phased out, so users of these old variants must now move
to using standalone eplex.<BR>
<BR>
There are some differences at the source level between standalone and the
older non-standalone eplex. This chapter outlines these differences to help
users to port their existing code to standalone eplex.<BR>
<BR>
<A NAME="toc29"></A>
<H2 CLASS="section"><A NAME="htoc47">4.1</A>&nbsp;&nbsp;Differences between Standalone Eplex and Older Non-Standalone Eplex</H2>
The main difference between the standalone eplex and the non-standalone
eplex is that the standalone version does not use an ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP>
`bounds keeper' like lib(ic) or lib(range) to provide the ranges for the
problem variables. Instead, ranges for variables are treated like another
type of eplex constraint, i.e., they are posted to an eplex instance, and
are stored with the external solver state.<BR>
<BR>
In the non-standalone eplex, the bounds of <I>all</I> problem variables are
transferred from the bounds keeper to the external solver each time the
solver is invoked, regardless of if the bounds for the variables have
changed or not since the last invocation. This can become very expensive if
a problem has many variables. With the standalone eplex, this overhead is
avoided as the external solver bounds for variables are only updated if
they are explicitly changed. A possible inconvenience is that for hybrid
programming, where eplex is being used with another ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> solver, any
bound updates due to inferences made by the ECL<SUP><I>i</I></SUP>PS<SUP><I>e</I></SUP> solver are not
automatically transferred to the external solver. This can be an advantage
in that it leaves the programmer the freedom of when and how these bound
changes should be transferred to the external solver.<BR>
<BR>
The main user visible differences with the non-standalone eplex are:<BR>
<BR>

<UL CLASS="itemize"><LI CLASS="li-itemize">
Bounds constraints intended for an eplex instance should be posted to
that instance, e.g.
<PRE CLASS="verbatim">

[eclipse 3]: eplex_instance(instance).
...

[eclipse 4]: instance: eplex_solver_setup(min(X)), 
        instance: (X:: 0.0..10.0), instance: eplex_solve(C).

X = X{0.0 .. 10.0 @ 0.0}
C = 0.0
Yes (0.00s cpu)

</PRE>
The ::/2 ($::/2) constraints are treated like other eplex constraints,
 that is, the bounds for the variables are specific to their eplex
 instance. Other eplex instances (and indeed any other bounds-keeping
 solver) can have different and even incompatible bounds set for the same
 variable. Also, if the variable(s) do not already occur in the eplex
 instance, they will be added. Both of these are different from the
 non-standalone eplex, where bound constraints were treated
 separately from the eplex constraints.<BR>
<BR>
Like other eplex constraints, inconsistency within the same eplex instance
 will lead to failure, i.e. if the upper bound of a variable becomes
 smaller than its lower bound, this will result in failure, either
 immediately or when the solver is invoked.<BR>
<BR>
One potential problem is that with the non-standalone eplex, the bound
keeper's <CODE>::/2</CODE> was re-exported through the eplex module (but not
through the eplex instances). One was able to write
<CODE>eplex: (X :: 1.0..2.0)</CODE>
and affect the bounds of the variable for <I>all instances</I>,
even though this was not posting a constraint to any eplex instance.
With the standalone eplex, the same code, <CODE>eplex: (X :: 1.0..2.0)</CODE> has
different semantics and <I>is</I> a constraint for the eplex instance
<CODE>eplex</CODE> only. <BR>
<BR>
A variable never becomes ground as a result of an eplex instance bound
constraint, even when the upper and lower bounds are identical. <BR>
<BR>
Posting eplex arithmetic constraints involving one variable is the
same as posting a bounds constraint. Unlike the non-standalone eplex, the
variable will be added to the eplex instance even if it does not occur in
any other constraints.<BR>
<BR>
No propagation of the bounds is performed at the ECLiPSe level: the bounds
are simply passed on to the external solver. In general, the external
solver also does not do any bounds propagation that may be implied by the
other constraints in the eplex instance. <BR>
<BR>
Note that the generic <A HREF="../bips/kernel/termmanip/get_var_bounds-3.html"><B>get_var_bounds/3</B></A><A NAME="@default202"></A> and <A HREF="../bips/kernel/termmanip/set_var_bounds-3.html"><B>set_var_bounds/3</B></A><A NAME="@default203"></A>
applies to <I>all</I> the eplex instances/solver states. If set_var_bounds/3
is called, then failure will occur if the bounds are inconsistent between
the eplex instances.<BR>
<BR>
<LI CLASS="li-itemize"><A HREF="../bips/lib/eplex/integers-1.html"><B>integers/1</B></A><A NAME="@default204"></A> only indicates that a
variable should be treated as an integer by the external solver in the
eplex instance, but does not impose the integer type on the variable. 
In addition, the type of the solution returned for a variable is determined
only by if it was in an <TT>integers/1</TT> declaration for the eplex instance.
(In non-standalone eplex, the type is determined by the type given the
variable by the bounds keeper)<BR>
<BR>
<LI CLASS="li-itemize">If a bounds keeper like lib(ic) is loaded, then any bounds
constraints posted to this solver are <I>not</I> automatically visible to
the eplex instances. Instead, the bounds can be transferred explicitly by
the user (e.g. by calling the eplex instance bounds constraints when the
bounds in the solver changes). To allow for more compatibility with the
other versions of eplex, the <CODE>sync_bounds(yes)</CODE> option can be
specified during solver setup (using <A HREF="../bips/lib/eplex/eplex_solver_setup-4.html"><B>eplex_solver_setup/4</B></A><A NAME="@default205"></A>). This will `synchronise' the bounds of all problem
variables when the external solver is invoked, by calling
<CODE>get_var_bounds/3</CODE> for all problem variables. Note that it is the generic
get bounds handler that is called. <BR>
<BR>
<LI CLASS="li-itemize">When a demon solver is invoked, the update to the objective 
variable is via an update to its bounds. In the standalone eplex, this is
done by calling the generic <CODE>set_var_bounds/3</CODE>. However, if there are
no bounds on this variable, the update will be lost. A warning is given
during the setup of the demon if the objective variable has no bounds. <BR>
<BR>
One possible solution is to add the objective variable to the problem
(e.g. by giving it bounds for the eplex instance). However, this can induce
extra `self-waking' that needlessly invokes the solver (e.g. if the bounds
trigger option is used). Another solution is to add bounds to the variable
via some other bounds keeper, e.g. <CODE>lib(ic)</CODE>. Note that it is always
possible to retrieve the objective value via the <CODE>objective</CODE> option of
<A HREF="../bips/lib/eplex/eplex_get-2.html"><B>eplex_get/2</B></A><A NAME="@default206"></A>.<BR>
<BR>
<LI CLASS="li-itemize">When a constraint is posted to an eplex instance after solver setup,
that constraint is immediately added to the external solver, rather than
only `collected' by the external solver when it is invoked. <BR>
<BR>
<LI CLASS="li-itemize">The solver setup predicates have been simplified in that the
suspension priority is no longer specified via an argument, so these
predicates have one less argument:
<A HREF="../bips/lib/eplex/eplex_solver_setup-4.html"><B>eplex_solver_setup/4</B></A><A NAME="@default207"></A>,
<A HREF="."><B>lp_demon_setup/5</B></A><A NAME="@default208"></A> Instead, the priority can be specified as an option, if
required. The older predicates with the priority argument are still
available for compatibility purposes.
<LI CLASS="li-itemize"><A HREF="../bips/lib/eplex/eplex_get-2.html"><B>eplex_get/2</B></A><A NAME="@default209"></A> and <A HREF="../bips/lib/eplex/lp_get-3.html"><B>lp_get/3</B></A><A NAME="@default210"></A> now has an extra option:
<CODE>standalone</CODE> which returns the value <CODE>yes</CODE> for standalone eplex
and <CODE>no</CODE> otherwise.<BR>
<BR>
<LI CLASS="li-itemize">The order in which variables are passed to the external solver has
 changed. Also, with standalone eplex there may be more variables in the
 problem. This should not be visible to the user, except when examining a
 problem written out by the external solver. This makes it difficult to
 compare problems generated using standalone eplex and non-standalone
 eplex. Using the <CODE>use_var_names(yes)</CODE> options in setup should make
 this somewhat easier as the variables would have the same names.</UL>



<HR>
<A HREF="obsman003.html"><IMG SRC ="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC ="contents_motif.gif" ALT="Up"></A>
<A HREF="obsman005.html"><IMG SRC ="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
